A color space is a model for representing color numerically in terms of three or more coordinates, e.g., the RGB color space represents colors in terms of the Red, Green and Blue coordinates.
For color to be reproduced in a predictable manner across different devices and materials, the color has to be described in a way that is independent of the specific behavior of the mechanisms and materials used to produce the color. For instance, color cathode ray tubes (CRTs) and color printers use very different mechanisms for producing color. To address this issue, current methods require that color be described using device independent color coordinates, which are then translated into device dependent color coordinates for each device. Presently, the device itself provides the mechanism for translation into the device dependent system.
In this regard, color management is a term that describes a technology or system that translates the colors of an object, e.g., images, graphics or text, from their current color space to the color space of the output devices like monitors, printers, and the like.
Early on, operating systems supported color by declaring support for a particular color space, e.g., RGB; however, since RGB varies between devices, color was not reliably reproduced across different devices.
Since such traditional means of color support were inadequate, various operating systems added support for using International Color Consortium (ICC) profiles to characterize device dependent colors in a device independent way. The ICC device characterization profile specification is publicly available and may be obtained, for instance, from the ICC web site, i.e., www.color.org. ICC uses the profiles of the input device that created an image and the output device that displayed the image and creates a transform that moves the image from the input device's color space to the output device's color space. While this resulted in very accurate color, it also involves the overhead of transporting the input device's profile with the image and running the image through the transform.
Further techniques were then developed in an attempt to provide intermediate device independent standardized color spaces. Some of these color management techniques already exist in operating systems and applications today, such as MICROSOFT® WINDOWS® operating systems and MICROSOFT® OFFICE® platforms. Color spaces other than the ICC color space include the standard color space, or sRGB for short (International Engineering Consortium (IEC) Specification No. 61966-2-1), which has been supported as a core technology beginning with WINDOWS98® and OFFICE2000®. Color management techniques have continued to evolve through the authoring of the standard extended color space, or scRGB for short (IEC Spec. No. 61966-2-2).
With integration of ICC, sRGB and scRGB, there are a number of issues that require resolution when it comes to the various types of input and output computing devices that support color. Currently, sRGB is the default color space in Windows, based on the IEC 61966-2-1 standard. An sRGB-compliant device does not have to provide a profile or other support for color management to work well.
In this regard, the structures of the sRGB, scRGB and ICC color spaces have a fixed and definite meaning, and are background to the invention. While reference to these color spaces has meaning that constitutes sufficient identification to anyone of ordinary skill in the art, a generic description nonetheless follows, and may be supplemented by any of the publicly available standards specification for the respective color spaces.
The standard RGB color space, sRGB, includes 1-D Look Up Tables (LUTs) describing nonlinear relationships between the tonal response of RGB perceptual space and physical luminance space, such as CIEXYZ, a 3×3 matrix describing red, green and blue primaries as they relate to CIEXYZ values, white point value in perceptual terms, such as D65 for a CIEXYZ standard correlating to daylight as a color temperature of 6500 Kelvin and optional viewing conditions such as surround, background, brightness that impact an end user's perception of the target device colors.
The standard extended color space, scRGB, is the same as sRGB, but the values can extend outside of the visual range of colors.
An ICC profile is typically a metadata structure that includes information relating device dependent colors to their equivalent human visually perceived colors. Some instances of ICC profiles can also provide translation information between any two color spaces, whether device dependent or device independent.
The X Protocol was developed in the mid 1980's in response to the need to provide a network transparent graphical user interface (GUI) primarily for the UNIX operating system. X provides for the display and management of graphical information, much in the same manner as MICROSOFT® WINDOWS® and IBM®'S Presentation Manager.
The key difference between the X architecture and the color management techniques of other platforms is in the structure of the X Protocol. Whereas WINDOWS® and other platforms, such as IBM's Presentation Manager, simply display graphical applications local to the PC, the X Protocol distributes the processing of applications by specifying a client-server relationship at the application level. The “what to do” part of the application is called an X client and is separated from the “how to do” part, the display, called the X server. X clients typically run on a remote machine, which has excess computing power and displays on an X server. The benefit is true client-server and distributed processing.
As illustrated in FIG. 1A, the X Protocol defines a client-server relationship between an application 210a, 210b and its display 240. To meet this, the application 210a, 210b, called an X client, is divorced from the display, known as the X server 240. The X clients 210a, 210b include an X library 220, and optionally a toolkit 230. X server 240 includes device drivers 250 for driving a device 260. As shown in FIG. 1B, X further provides a common windowing system by specifying both a device dependent 200b and an independent layer 200a, and basing the protocol on an asynchronous network protocol for communication between an X client 210 and X server 240. In effect, the X Protocol hides the peculiarities of the operating system and the underlying hardware. This masking of architectural and engineering differences simplifies X client development and provides the springboard for the X Window System's high portability.
Advantages of the X approach include: (1) local and network based computing look and feel the same to both the user and the developer, (2) the X server is highly portable allowing support for a variety of languages and operating systems, (3) X clients also have a high degree of portability, (4) X can support any byte stream oriented network protocol, local or remote and (5) applications do not suffer a performance penalty.
Thus, the design of the X Protocol specifies a client-server relationship between an application and its display. In X, the software that manages a single screen, keyboard and mouse is known as an X server. An X client is an application that displays on the X server and is sometimes referred to as “the application.” The X client sends requests, e.g., a drawing or information request, to the X server. The X server accepts requests from multiple clients and returns replies to the X client in response to information requests, user input and errors.
The X Server runs on the local machine and accepts and demultiplexes network based or local interprocess communication (IPC) based X client requests and acts upon them. The X server (1) displays drawing requests on the screen, (2) replies to information requests, (3) reports error(s) in a request, (4) manages the keyboard, mouse and display device, (5) multiplexes keyboard and mouse input onto the network, or via local IPC, to the respective X clients, (6) creates, maps and destroys windows and (7) writes and draws in windows.
The X Client is essentially an application written with the aid of libraries, e.g., Xlib and Xt, that take advantage of the X Protocol. The X Client (1) sends requests to the server, (2) receives events from server and (3) receives errors from the server.
With respect to requests, X clients make requests to the X server for a certain action to take place, e.g., create window. To enhance performance, the X client normally neither expects nor waits for a response. Instead, the request is typically left to the reliable network layer to deliver. X requests are any multiple of 4 bytes.
With respect to replies, the X server responds to certain X client requests that require a reply. It is noted that not all requests require a reply. X replies are any multiple of 4 bytes with a minimum of 32 bytes.
With respect to events, the X server forwards to the X client an event that the application is expecting, including keyboard or mouse input. To minimize network traffic, only expected events are sent to X clients. X events are 32 bytes.
With respect to errors, the X server reports errors in requests to the X client. Errors are like an event but are handled differently. X errors are the same size as events to simplify their handling. They are sent to the error handling routine of the X client as 32 bytes.
The design of an X server depends greatly upon the platform hardware and operating system on which it is implemented. As the capabilities of the underlying technologies have increased, so have the power and capabilities of the X server.
As mentioned, FIG. 1A illustrates that there is a device dependent layer 200b of the X protocol and a device independent layer 200a. The device dependent layer 200b is responsible for localizing the X server to the native environment, be it WINDOWS or Solaris and for swapping bytes of data from machines with differing byte ordering, and byte ordering is noted in each X request. Layer 200b hides the architectural differences in hardware and operating systems and also maintains device driver dependencies for the keyboard, mouse and video.
For a single threaded architecture, the X server is a single sequential process using the native time-slice architecture for scheduling demultiplexing requests, multiplexing replies, events and errors among X clients.
For a multithreaded architecture, the X server is a multithreaded process capable of exploiting the nature of the operating system by breaking jobs into multiple threads for the operating system and hardware to perform. True preemptive multitasking, multithreaded environments offer a high degree of power for the X server.
Today's X Servers include workstations, X terminals and PC X servers. Workstations are powerful enough to handle complex computing requirements and usually display local X clients and a small percentage of network (remote) X clients. X Terminals are dumb terminals with graphics capability. X server software is downloaded from a host. X terminals are less expensive than workstations and simpler to maintain. PC X Servers integrate PC and remote application server access into one common desktop, leverage existing PC investment and user skill sets (desktop manipulation and access), provide local or remote window management at the user's preference and are easy to use.
The X Consortium established the X11 graphics architecture. Over the last several years, the desktop has evolved from a productivity or user-centric environment to one focused on centralized administration surrounded by the adaptation of Web protocols and a browser based user interface. The latest release of the X Window System from the X Consortium—X11R6.5.1, or X11 or X11R6 for short—has addressed the issues of integrating X applications and browsers enabling rapid deployment without re-coding and security.
The most recent release of the X11 graphics architecture is publicly available on the World Wide Web, at least from the X Consortium, www.x.org. In short, the X11R6 color management system is a graphics protocol, which, via operations including white point adaptation, gamut mapping, matrix conversions and one dimensional (1-D) Look Up Tables (LUTs), (1) supports color management functions that are pluginable and (2) supports translation of device independent application content to device dependent color values.
When the X Consortium established X11, X11 supported a very simple color management mechanism to convert between standard RGB colors to specific display device RGB colors using a 3×3 matrix and 3 1-D LUTs. With the advent of X11R6, the X color management system (Xcms) architecture was incorporated, based upon work by Tektronix that expanded the previous simple solution, to provide a method of conversions between a plethora of device independent color spaces to display device dependent color. This solution focused on adding white point chromatic adaptation support and gamut compression support. X11r6 color management thus assumes a workflow that begins with three channel device independent colors and converts to display device dependent colors.
The X11r6 architecture thus has two color management solutions. The first solution is the simple 3×3 matrix and 3-1D LUTs that are commonly used to characterize simple display devices, such as CRTs. The second is Xcms, which consists primarily of a white point conversion and gamut compression. Since the introduction of Xcms, color management has advanced and found solutions limited to these two techniques are inadequate because most assume source and destination devices where X11 only supports a destination device and assumes the source is device independent.
Also, modem color management solutions based upon metadata device characterization profiles, such as the ICC, assume the workflow begins and ends with three, four or more channels of device dependent colors. Presently, X11 only enables a color management workflow that begins with three device independent colors and ends with RGB display device dependent colors. Modem color management solutions based upon standard color spaces, such as sRGB and scRGB, are similar to modem metadata solutions, except the metadata is contained within the device itself, so that the workflow appears to be completely device independent outside of the source and destination devices. Essentially the metadata converting between device colors and the standard color space exists only within the source and destination hardware itself. This allows for much simpler user experiences and exchange of color content in open networks and also allows complex workflows consisting of multiple applications or users.
Other prior art solutions that exist today do not presently integrate with X11R6 and are thus are limited to a single application. Accordingly, cut and paste, inter-application and complex workflows are very limited with present solutions. Moreover, present solutions are very limited with respect to supporting Cyan, Magenta, Yellow and blacK (CMYK) and other color spaces. Thus, there is a need for a mechanism that enables the standard X11r6 graphics platform to support the industry de facto metadata color management standard built around the ICC, sRGB and scRGB color management systems, respectively. There is still further a need for a mechanism that allows support for modem color management standards, such as ICC, sRGB and scRGB, which begin and end with device dependent colors.